I think the ideal thing would be if I could get this patch finished and get back to the development version where there is tyre physics to work on.

It's not possible to make a perfect drift car by changing a few values on a racing car in a flawed tyre physics model. It's not going to happen, because impossible things can't happen.

I don't think there's too much point arguing about 10mm which makes such a tiny difference. I believe people were saying (as I found myself) that the FZR was faster than the XRR. I hoped to improve that with this update, by making such a tiny change to the XRR's tyre width, doing the same at front and rear so as not to affect the car's balance.

I am aware that both of these cars have illegal rear tyre width compared with Formula D. But they aren't purpose built drift cars. This is an update to allow people to drift our racing cars, as requested.

But I described this all in a previous post so why am I going through it again?

Quote from martin18 :

Scawen I've done more research and more testing with other players too. Reasons why WE think we need 3 configurations for FZR and XRR are:

Thanks for the feedback.

I have come up with one small change to try but I'm not prepared to spend time trying to make a proper drift config. There is no possible way that could be 'right' with the existing tyre physics and no possibility of even using a vehicle editor. I've just about reached the end of what I can do for this update.

Remember these incompatible changes were meant to allow some more fun for drifters and other racers. There was no intention to try and create a proper drift car.

The only thing I can really do at this time is try to adjust the existing config in such a way that it tries to keep everyone a little bit happier than they would have been, but obviously not as happy as they could be if they had a real vehicle editor with hundreds of adjustments. I would still like that to be the case one day. But the only way to move in that direction is if I get back to the development version.

There are way too many changes that would be needed to make a proper drift car and I don't even think I am the one to do it. It would be a big project. Actually I propose to remove the "DRIFT / RX" name and go for "ALTERNATE" instead. No real point selling it as a drift car, because is hasn't been properly developed for that. It has just had a few changes that make drifting and rallycross possible.

So for now the suggestion I have is to simply increase the XRR front and rear tyres by 10mm each. This makes the car fractionally faster and more competitive with the FZR. I've tested it and to me the balance feels OK and I managed to lap 6 tenths faster than the other day. I won't change the spacing. So the outer edge of the wheels are 5mm further out.

Thanks for the feedback. I've now released another incompatible version. I've tried to sort out the most important issues and also tried to improve the balance of the GTR cars with the new configurations as a hard track racing category.

I can't change tyre physics or the properties of layout objects in this update. Those are more serious physics changes and I can't put time into that now as the development version is too different.

This update is intended to give more variety in drifting, hard track racing and rallycross. I'd be interested to hear from some better sim racers than me (that's most of you) how lap times compare with the GTR cars and how well the tyres work in the new configurations.

Changes in 0.6U19 (NEW INCOMPATIBLE VERSION)

Maximum number of layout objects increased to 2400
XR GTR in DRIFT / RX config has H-pattern shifter
Handbrake strength is now separately adjustable
10mm narrower rear tyres in XR GTR new config
10mm narrower F/R tyres in FXO GTR new config
10mm narrower track width FZ50 GTR new config
Tyre size displayed in Tyres tab in Garage
FIX: InSim IS_NPL did not report Config

https://www.lfs.net/forum/thread/95016

Last edited by Scawen, Mon 8 Feb 2021, 12:45.

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST


THIS PATCH IS NOT COMPATIBLE WITH VERSION U


Hello Racers,

Here is a new test patch: 0.6U25

The changes are listed below.

0.6U25 is NOT COMPATIBLE with 0.6U

- You can NOT connect online with 0.6U
- You CAN play replays from 0.6U

Please back up or rename your LFS.exe from version U so you can revert to it if necessary.


Changes from 0.6U23 to 0.6U25: COMPATIBLE WITH U23

Steering:

Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash

Training:

FIX: AI changed to low fuel load if overtaking lesson restarted
FIX: AI skill / admin commands no longer processed during training
FIX: Training lesson did not end if replay saving was interrupted
FIX: Refuelling depended on refuelling allowed in single player
FIX: Logo was visible under title during lesson replay

Misc:

Removed debug message "Replay name : temp_mpr"
Saving replay name now shown beside option in Options - Game
Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)

InSim:

IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race

OutSim:

OutSim packet is documented in docs\OutSimPack.txt
Added steering torque as additional field in new OutSim
All data options can be switched on with OutSim Opts 1ff

Translations:

More updated translations. Thank you very much, translators.


Changes from 0.6U16 to 0.6U23: NEW INCOMPATIBLE VERSION

Multiplayer prediction:

Position packet now includes contact patch offset for each tyre
Wear and temperature packet is more frequent and more accurate

Pit stops:

Command /canrefuel (no/yes) to set refuelling allowed in pit stops
Damage repair not required when changing tyre pressure or compound

New ALTERNATE setup configuration for the five GTR cars:

Selecting the new config in XRR/FZR/FXR decreases tyre width a bit
With alternate config, narrower tyres may be selected (adds offset)
Also ROAD_SUPER, ROAD_NORMAL, HYBRID, KNOBBLY tyres may be selected
High "Maximum Lock" is possible in XRR/FZR with narrower wheels
XR GTR in ALTERNATE config has H-pattern shifter

Tyre choices and steering lock:

XFR and UFR maximum steering lock increased to 30 degrees
LX4 and LX6 maximum steering lock increased to 45 degrees
Single seater racing cars can now use ROAD_SUPER tyres
Steering wheel turn amount changes with maximum lock

New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:

LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored

Controls:

Handbrake strength is now separately adjustable

Graphics:

Avoid upward lighting related to ground colour in internal views

InSim:

Config byte added to IS_NPL packet indicates setup configuration
IS_CPP Pos is now relative to "Centre view" not the user setting
IS_NPL RWAdj / FWAdj indicate rear / front tyre width reduction
New bytes set if /showfuel=yes: IS_NPL Fuel / IS_PIT FuelAdd
IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining

Interface:

Tyre size displayed in Tyres tab in Garage
Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
When alternative config is selected F12 display shows tyre size
/press and /shift commands now support 'minus' as parameter
minus key (block messages) now works in free view mode

Misc:

Maximum number of layout objects increased to 2400
You can now add up to 32 local drivers (real + ai) in multiplayer
Restored code preventing 2 cars joining autocross within 3 seconds
FIX: Wrong warning "Road tyres on rallycross track" in hotlapping

Translation update for help.txt:

host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0

Translations:

Many updated translations. Thank you, translators.


Changes from 0.6U to 0.6U16: FINAL VERSION COMPATIBLE WITH 0.6U

Interface:

Pit speed limit is shown when car speed is below 2/3 of limit
Yellow and blue flags now alternate with RCM or penalty message
Prevented auto-repeat on block message and light switching keys
Command /spectv no - prevent selecting TV camera on spectate
Momentary flick to rear view after SHIFT+R is now avoided
Avoided downshift after pressing SHIFT+X to exit free view
In fact any 'key held' function after SHIFT+key is prevented

F12 pit instructions:

Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop

Multiplayer:

Maximum packets per second (/pps) has been increased to 12
Rolling resistance included in catch-up phase of prediction
Reduced steering glitch each time a position packet is received
Position packets are sent more frequently in response to steering
Command /showfuel (no/yes) allows remote car fuel load to be seen
More accurate transmission of fuel load from local to remote car
Most admin commands with parameter omitted report current value
Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address
FIX: Remote cars with worn tread could wrongly get a puncture
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Stop-go penalty caused car to get stuck in custom pit stop
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

InSim:

IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
FIX: Free view roll is now reported in InSim IS_CPP packet

CPU usage display:

In Graphics or Misc options (in-game) click car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
MPR / SPR are prevented from being named temp_mpr / temp_spr

VR:

Updated OpenVR to version 1.10.30
Improved timing of obtaining view each frame
New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
Names over cars could fade differently in each eye in Pimax headset
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
FIX: Head tracking / mirrors wrong if car leaned with horizon lock
FIX: Free view FOV was wrong after entering VR in free view
FIX: Names above cars looked wrong in Pimax headsets
FIX: Some trees looked wrong in Pimax headsets

Skin downloads:

Faster skin downloads when joining server (and auto updater)
Slightly faster skin downloads when driver joins race in-game
FIX: Skin downloading could get stuck after a large header

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

Views:

Horizon lock now has a strength slider option
View filter time maximum value increased to 1 second
Improved key control (4/5/6/7) of free view field of view
Three screens are now assumed when aspect ratio is 4:1 (was 3:1)
Free view mode minimum field of view reduced from 10 to 2 degrees
FIX: Filtered view went wrong with low filter time + replay speedup

Graphics:

Car shadows now use anisotropic filtering to reduce shimmering
Increased distance for car subobjects to become invisible

Controls:

Gearshift debounce setting now applies to all controller buttons
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Rare manual shift at high speed to 1st/rev during auto shift

Force Feedback:

New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)

More telemetry data for OutSim:

Enable by setting the OutSim Opts value in cfg.txt
All data options can be switched on with the value ff
The new data is documented in a header file OutSimPack.h

Misc:

When LFS is set to close the reason is logged to deb.log file
Added a little more logging about D3D initialisation to deb.log
CAR.lfs scripts are reliably run when user car is spawned or reset
FIX: Memory leak related to threads (most often for skin download)
FIX: Replays from old Westhill before 2015 now marked as obsolete
FIX: Driver names ending with a lead byte could corrupt text
FIX: Issues with driver names ending with caret character


INSTALLATION:

A FULL version of LFS 0.6U must already be installed

To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.6U25


DOWNLOADS:

IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U25 (SELF EXTRACTING ARCHIVE)
www.lfs.net/file_lfs.php?name=LFS_PATCH_6U_TO_6U25.exe (1.8 MB)

FOR HOSTING ONLY:
DEDICATED HOST 0.6U25 (non-graphical version for hosting only):
www.lfs.net/file_lfs.php?name=LFS_S3_DCON_6U25.zip (1.8 MB)

Last edited by Scawen, Sat 27 Feb 2021, 14:11.

Thanks for the testing and reports.

Quote from Flotch :

How is this working : does more sleep mean more cpu "free" time ?

Yes. Sleep is done deliberately by LFS if you limit the frame rate or if "Sleep every frame" is set. It calls a function "Sleep(x)" which gives up x milliseconds to the operating system before continuing to process LFS code. It tries to do just the right amount of Sleep each frame to get down to the target frame rate.

"Flip" is a another kind of waiting time when we are waiting for D3D to finish and present the finished frame. One way to see that is if you use SHIFT+F11 (full screen borderless window) with vertical sync enabled.

I just noticed that if you use SHIFT+F10 (full screen exclusive mode) then all the extra CPU seems to be in "Draw" rather than "Flip" so I'll have a look why that is different from SHIFT+F11.

About your question "why would 31 AI with you cost less less cpu for physics than when alone". That should not be the case. More AI drivers should always use more CPU time for Phys. By the way, the CPU usage for the actual 'AI' is also included in "Phys" and Audio is also included there. But these are very small compared with the actual physics.

Last edited by Scawen, Sat 30 Jan 2021, 09:58.

Quote from Degats :

While you were digging around with pitstop code, did you get a chance to look into these bugs?
https://www.lfs.net/forum/thread/94490-InSim%3A-IS-PSF-STime-Inaccurate-On-TOC
https://www.lfs.net/forum/thread/94491-InSim%3A-Missing-IS-PSF-packet

I've added this to my notes file for the compatible patch.

Quote from tankslacno :

2) Actual bug, happened at least on FZR.

Thanks for the tests.

That FZR bug is one of the things I fixed yesterday, linked to by MandulAA above.

Quote from Eclipsed :

Regarding F12 menu and pitstop settings I have an improvement suggestion:
Once you accidentally switch from assymetric to symetric,you can't turn back so easily.

Thanks but I don't want to tackle that, as there is bug potential and complication there. Actually I'm just trying to stay sane while trying to get the compatible fixes done so I can get back to the incompatible fixes so I can release version V so I can get back to the development version and try to finish the graphics so I can get back to the tyre physics.

Thanks, got it and reproduced locally too.

Another similar bug can be reproduced with temperature. If you get the tyres very close to 200 (around 196 or so) then wheelspin a little (not exceeding 200 locally) the remote cars will get a puncture until the next wear packet arrives.

Yesterday I increased the accuracy of the transmitted fuel load as that became quite obviously inaccurate with the /showfuel option.

Car state (excluding damage) is covered by wear packets and position packets. The wear packet is for slower changing things, including fuel load, tyre temperatures and tread thickness. These changing values are worked out in physics on the remote cars but updated around every 10 seconds by a wear packet to keep them close to the local car. The position packet is of course for rapidly changing values.

In my tests I've included more in the position packet. As mentioned before, the initial tyre deflection which can stop some slight wandering of the car in the split second after the position packet arrives. In the next day or two I'll try including some of the tyre temperature data in the position packet to see if it makes much of a difference. Conceptually the tyre temperatures are somewhere between the slow changing and fast changing values. So maybe they would be better placed in the position packet rather than the wear packet. Although that's not quite such a no-brainer as you might imagine, because they are worked out physically in the remote instance anyway and they would cause quite an increase in the size of position packets. Anyway we'll see what the tests show.

Yesterday I was going through the other thread and seeing what other compatible changes I could get done. So there will be at least one more compatible patch before the incompatible ones.

Quote from Pasci :

Under certain circumstances, the outsourcing of AI drivers to the dedicated host would be a better solution than increasing the permitted number on the client side? It would be good if you could determine the "field size" and as soon as a real driver connects, the number of AIs is "dynamically" reduced (or increased if someone disconnects from the host).

AI on server would be good but our current DCon can't possibly do that, as it only has a very cut-down version of the tracks, not including the physical surfaces. It doesn't need them because it doesn't run physics. It is already possible with a full version of LFS running as the server but that requires a user name. A full version can run in 'dedicated' mode but currently runs in the same way as DCon. I think that option could be made to run physics but it's really beyond the scope of this minor update.

I only started this process to allow a wider range of settings. It's turned into a multiplayer prediction + various other things but I still want to get this done ASAP because there is a lot still to do in the development version.

Quote from THE WIZARD DK :

1. could this have had impact on the shifting thing?
2. i am using space bar with keyboard. will that be customizable?
or SPACE only?


also. i tried to go in single player mode.
with 21 cars (all types) and myself on track i still get those lagspike things at some times.
you asked me if i got that recently. it seems i do. patch u13. what can cause this then?

No, the packet sending rate due to speed limiter was only related to packets.

The space bar for VR click is not customisable and I don't have any plans to do so. This code was designed so that space bar when typing no longer interferes with VR click, for people with a VR headset.

I don't know why you have lags but I don't think it's related to this test patch. If it is to do with graphics card limitations (memory swapping) you could try lower texture resolution. Otherwise lags could be caused by other programs running on your computer.

No tyre and lock changes for the GTR cars yet, because that would make the version incompatible with the current one. As soon as I release the incompatible patch, then half the community will be on the official version and half will be on the incompatible new version, so the online experience becomes thinly spread. That's why it makes sense to first release any changes that do not make the version incompatible. Then they can be tested while I continue with the other incompatible changes.

For example, some of the changes I have been working on, involve additional data in the pospacket. I don't want to release one incompatible version then another one that is incompatible with that one, so we have all these U versions that can't connect online.

I'm trying to make the transmitted car state a better representation of the remote car, so that at least when inputs haven't changed much, the car should continue near the correct path, until the next packet arrives. A good example is BF1 at oval. The predicted remote car car be around half a car's width from the real car even when the controller inputs remain constant. I'm trying to reduce that error by looking at things, mainly in the tyre physics.

I've tested improving the initial start state of prediction including tyre deflection in the position packet. This improved something but not enough. I can also notice difference in the MPR when rewinding to different points. Some of this difference seems to be inaccuracy in the tyre temperatures and I've found that the currently transmitted tyre temperatures are not accurate enough and I plan to try sending a more accurate version in the position packets and see if that solves the predicted car's cornering inaccuracy.

Test Patch U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185

U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185

Thank you all for these results and observations.

It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.

The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.

I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.

Quote from Degats :

Looking at several replays, it appears that the smoothing is still working properly when watching replays in U13 only if the car you're watching was also on U13, but not if they were on older versions.

That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.

Quote from nexttime :

So it's not 12pps at all times?

No, that would cause an enormous increase in server bandwidth and intolerable CPU usage from the extrapolation (prediction) of the position of remote cars. In the case where the remote player has a high ping, the CPU usage can become quite bad because, every time a packet is received, LFS must run the full physics from when the packet was sent, up to the current time. That could be 100ms, so 10 full physics updates and if that was 12 times per second that would be 120 physics updates per second and this would exceed even the normal physics calculations.

I ask people to consider turn one situations when a lot of cars are close together and there is a lot of physics usage and the cars are drawn at high resolution and the frame rate drops. I am fully aware of this problem and I am always trying to avoid it.

Along with this huge cost, there would also be only tiny benefits, from sending more packets when the previous packet already provides a good prediction.

There's no point in using a sledgehammer to crack a nut.

This is why the code tries to send new position packets when the previous packet can no longer be considered to provide a good prediction of the car's location. This happens faster when there have been changes to the input provided by the user.

Quote from nexttime :

Shouldn't this be the other way round? At lower speeds people use quicker/wackier steering inputs & higher angles. And at higher speeds we all keep it smooth. (If by higher speeds you meant the vehicle speed and not steering wheel rotation)

When you are at higher speeds, you move the steering much smaller amounts. Before today's version, that would be interpreted as very little change to the input. But actually at high speeds your car moves across the road much more for a smaller steering input, that is why the steering-related packet frequency is now increased with speed.


EDIT: I don't claim this is the end of the job. I had some changes today that made sense and are moderate but noticeable enough, in my opinion, to be put out there for testing. It's safe and I want to play safe for now. This is a minor update for the existing public version and I need to be on this for as little time as possible.

Last edited by Scawen, Mon 11 Jan 2021, 20:32.

Quote from Nanex :

have the possibility of having slik tires on the TBOs as well

I think, because of how the physics system works, the road cars just flip in this case and actually this could spoil the fun of the road car racing.

Quote from w126 :

Please consider allowing co-drivers (with seats) in GTR cars. We could pretend they are rally cars and this wouldn't be totally unrealistic. For example, XF GTR is quite similar to 2-litre kit cars from late 90s and more powerful GTR cars may be thought of as part of R-GT group (https://en.wikipedia.org/wiki/Group_R-GT).

That is too much of a change in the current system. The changes we are discussing are really just about a few changes of limits, with no serious coding that I don't have time for in the old version at the moment.

Quote from Pathseeker :

will road tyres manage to hold temperatures at all on those cars?

All I know is that in some drift series they have used tyretools tweak software to allow these changes in the FZR and XRR for drifting. I haven't done any testing at all. I don't want to start trying to code new tyres. The aim here is only to allow what people are already doing but without the need to use memory modifying software.

Thanks for the feedback.

Quote from rattijonni :

Increasing the miniscule 6pps in multiplayer to atleast 12 should also be an easy and worth while change.

I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).

Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.

So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.

I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.

But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.

Quote from tankslacno :

Small question related to that AI-thing: since it requires us to connect to online to test it, could we test this patch on hosts rented on LFS.net or is the only way to test this is to download a Dedi host for that patch or start a new server from LFS itself?

Good question, I'll need to ask Victor about this.


Other comments - thanks for the feedback. I'm reading and thinking...

Hello Racers,

Since the September update we have kept working hard. Eric has continued with South City, which is now a very open town area with many connecting roads. There are car parks, squares, back streets and new roads. It has taken longer than any of us expected because of the size of the area and amount of detail. My work has also taken many turns, supporting the new open city area as described in previous reports. Eric will now be starting on Fern Bay although there are still things to be finished at South City and Kyoto. I decided to present this progress report as a cut down list of updates from a few development versions since September. It gives a little insight into the process without going into too much detail about many other minor changes that there are in each version. Be warned, although cut down it's still a list of technical changes! It may be best to scroll down and look at the screenshots.


23 Oct - Lighting updates

More accurate baked lighting render for artificial lights. Drawn at higher resolution which allows more accurate results from small, bright lights in the middle distance, but with changes that allow it to run faster. Other track editor improvements. Some changes so that the apparent brightness of lights corresponds exactly with their actual lighting effect. Improved automatic exposure quality by analysing a larger texture in the compute shader.

30 Oct - Turbine updates

Wind turbines now use static vertex buffers, similar to the way a car is drawn. This allows higher resolution turbine models. The turbine code was generalised to allow 3D clock hands for city buildings.

02 Nov - Editor updates

More editor updates to allow easier positioning and alignment of objects.

13 Nov - Updates for sections

Physics enabled for the triangles on sections. Sections are the cross-sectional objects between the segments which are used for most physical surfaces in LFS (e.g. road, fences, walls). Some sections have their own surfaces (e.g. at the end of a wall) but previously they were non-physical. Editor updates to allow easier selection of objects. Slight changes to ensure that triangles on some types of connected objects are in exactly the same place, to avoid light bleeding through cracks.

20 Nov - Various editor improvements and fixes

Doubled the speed of the offline occlusion render by use of batched rendering. Enabled lights on turbines and clocks. Shader optimisation, using 4x3 matrices instead of 4x4 where possible.

18 Dec - Updates for collision with unmovable objects

Updates to the physics of unmovable objects (e.g. buildings, grandstands, smaller objects). Previously, unmovable objects used the same system as as movable objects. Now they have a more compact mesh which saves memory and CPU usage. They are now stored in the same map square system as the sections and segments. The map square system has been upgraded, to reduce the CPU time for detecting nearby objects. A discontinuity in the trunk physics calculation has been removed.

A new visualisation for the track editor shows the physical world clearly, including the physics meshes and trunk objects. Objects now have a 'surface type' that was previously only available for segment surfaces. More surface types have been added, such as rubber (tyres and some barrier linings), wood (several fences) and plastic (various barrier signs and temporary barriers). An intermediate scrape sound effect has been added for wood and plastic, avoiding the soft impact sound and the metallic scrape. The calculation for the stereo effect of the scrape sound has been improved. The colour of dust kicked up by tyres is now either white or beige depending on the surface, instead of taking on the average colour of the surface.


Eric has sent some screenshots of the latest version of South City. We hope you like the pictures.

Remember to check out the LFS calendar for racing events and follow us on Twitter.

Have a good holiday!

Thanks for the feedback!

I decided to keep it after hearing that it is in use. I did copy, paste and simplify of the code that deals with recent impacts (the code that tries to reduce one collision event that happens over several physics frames, into a single output and avoids packet spam if there are multiple contacts with the same object in a short time). The newly added system is actually simpler (internally) because it is only concerned with local cars vs unmovable objects. It did no harm to add a few functions that work with the new style of unmovable objects.

Quote from cargame.nl :

Can be, it actually would improve the situation as it was always confusing on South City layouts.

In theory it should be easy to avoid any confusion by filtering on one bit in the OBHFlags field of the IS_OBH packet. The OBH_CAN_MOVE bit is set on all movable objects.

I think there are only 3 cases reported:

Movable, layout object - OBH_CAN_MOVE and OBH_LAYOUT are set
Movable, non-layout object - OBH_CAN_MOVE is set / OBH_LAYOUT *not* set
Unmovable, layout object (as discussed here) - OBH_CAN_MOVE is *not* set / OBH_LAYOUT is set

Unmovable, non-layout objects were always excluded because there were problems e.g. packet spam when a single seater car went around a corner with the new 3D kerb objects and a part of the body was scraping those objects.

Hello programmers,

I've come across this again in the code and think I should ask you again now that the current system has been around for years.

I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.

But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.

I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.

Movable objects would continue to be reported as before.

I don't have time to get into tyre physics at the moment but had some thoughts on it after Eeekie's post.

I think there are some competing effects when the throttle is applied.

1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.

2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.

3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.

Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.

These are good questions but I'm not getting into tyre physics now.

I can't remember everything and will be starting with a good look into what we have and what is covered and what is not.

Quote from DMN_ :

good job! I can't wait to progress from the Fern Bay track.
Will a future update work fairly well with the integrated graphics card? I have intel hd 4000 and currently max 60 fps at the maximum graphics settings.

It is hard to know but I will try to allow enough settings to run OK on lower spec computers. For example shadow maps can be made quite a lot faster by reducing the number of cascades and the distance that can be rendered, and switch off shadows in mirrors. Also you can switch off HDR mode, reduce texture resolution etc.

Quote from Pathseeker :

Awesome job Scawen! So initialy we might get new tyres with some mistakes, but then with some updates you will bring them to level you expect to reach? Or you think you will have enough time to make them to level you want with the update?
Also what we can expect performance wise from new tyres? Will initial grip level will be the same, or there will be quite diffirence?

I can't really release them as they are because you can exploit the issues. So I hope to make them a better approximation of reality so that they are fun to drive on and respond in realistic ways to changes in settings. As far as I remember, total grip was actually less but they feel better and more intuitive, so actually more fun to drive. One example, sometimes in the RWD cars, in the old physics, you can put on a little more power and the car seems to follow a wider line, which shouldn't really be the case when you add more longitudinal force to the rear tyres. In reality and in the new system, more power in a RWD car always results in the car taking a bit tighter line. This is because the combination of forces is now done in a way that makes more sense and has a mathematical basis. The public version is more like a made up force combination, adjusted to try to match reality.

Quote from BerdyGaming :

One thing that might be an issue is viewing the track from the free cam if things are rendered based on the car location. Is there something I'm missing in the explanation?

The free view video is only a demonstration. That mode is activated by a special button available in the development version so I can check how the occlusion is working. The free view doesn't use occlusion data normally, and doesn't need it so much as it's only the one view and no mirrors.

Quote from Flotch :

not yet
It disturbs me a lot when I play a little in LFS and see the GPU temperature almost as it was idle whn I quit ... while other games like ACC are bringing it to 80°c

The fan can speed up quite a bit these days. The shadow maps, more complex shaders, higher resolution textures, more detailed models, HDR and bloom effect are definitely using more GPU power.

Quote from Evolution_R :

The other major thing was:
[graphics and physics on separate threads]

But I guess that is maybe after the graphics are done.

Yes this would be helpful for maintaining high frame rate as the CPU still has do do a lot of work asking the graphics card to draw things. So I will be thinking about this probably when I'm on the physics.

Quote from nacim :

Wow, I'm really impressed by the ammount of work put into South City, good job !

@Scawen: You moved histogram generation on the GPU, that's nice to see, and looking at the settings that you got to tweak it, I feel like we saw similar papers for it.
Did you had to move to feature level 11 for it or did you found a way to make it work in feature level 10.0 ?

I did have to use 11 because InterlockedAdd was not allowed in feature level 10 and I couldn't think of another way to add to the histogram buffer.

Some possibilities here, the old 'read back a small texture and analyse on CPU' is still there for test purposes, so could be resurrected for Direct3D 10 GPUs. But I was thinking maybe feature level 10 could use the SDR mode and use time-based exposure instead. That would allow D3D10 graphics cards to use LFS but some things wouldn't be much good, e.g. it would be very dark in a car park.

But I don't know how many people have a Direct3D 10 graphics card as D3D10 was out a relatively short time before D3D11 was available. I think for now I'll keep trying to make sure it can run on them using SDR.

Quote from Aleksandr_124rus :

Nice, but i remember there has problems with merging code of the two LFS builds, how progress is going on now of merging builds with tire physics and graphics, or it is done now?

The new tyre physics is in this new version. So the situation is that it might be a bit hard to try to copy the old tyre physics from the public version, into this new version. I am more motivated to try and update the new tyre physics to an acceptable level. It is nice to drive with but needs some good work on load sensitivity, pressure and temperatures which are not correct.

Quote from MagicFr :

Always nice to see improvements in LFS Well done.
my 2 cents for VR as a only-VR user. and having tested auto-exposure in iRacing.
It doesn't work well in VR as the whole view is taken by the game, opposite to when looking at a game on a monitor ( or triple ) that take only , maybe 25%, of your FOV.

Yes, I found in VR the exposure is calculated as dark if you use the whole view, because so much of the view is the car interior, so then it overexposed the image. So in LFS it limits the exposure check to a smaller square in each eye (both added together for a single exposure histogram). This limited square is 30 degrees each way, equivalent to a 60 degree FOV on a square monitor.

Thank you for the feedback, pleased you like the progress so far.

I have a bit more to do on the graphics, though I want to spend some time on the physics soon.

A couple of urgent things I can think of.

- I want to convert the 'individual car diffuse lighting calculated from dynamic environment map' into a compute shader so I can use it for all the cars that have an environment map. More distant cars will use the 'approximate diffuse' lighting that is currently in the paths. That's only about a day or two's work, I think, as it's a simple compute shader (and a conversion of existing code).

- The approximate lighting, for more distant cars and will also be useful for temporary objects like physics objects, layout objects and skid marks. It always was stored in the paths. But now I think it can use the occlusion octree, as that already covers all driveable areas. This sounds like a few days work.

- One obvious thing is clouds in the sky but I really don't want skies to prevent work on the physics. In my mind this can be released without clouds, but cannot be released without the physics updates.

- Various things on paper lists here but I am actually crossing them off faster than adding them now.

On Eric's side there are still plenty of holes and gaps at South City, mainly because there are really a lot of new roads and connections and he has been filling those new places up with detailed buildings. Some more holes to fill at Kyoto, and there is Fern Bay too. So both of us will still be busy for quite a while.

Quote from Degats :

Eric's been busy

Obligatory comparisons:

Thanks for the comparison shots!

Quote from kagurazakayukari :

Wow! a lot of information!
Blow my mind XD

Again, had translated into Chinese~

Thank you for that!

You reached a point which is outside the map square system. The rectangle of map squares is set to the size big enough to include all the default ground that is set to have physical properties. Outside that, there are no map squares for your objects to be registered on.

The map squares system is designed to rapidly identify nearby objects to check for physical contacts during each frame's physics calculations.

On the 'already existing mods causing bad collisions' reported issue:

Quote from MacedoSTI :

This is not mysterious system
we just use a stock vob files based on new cars, this don't change colisions and hitbox, only the "3d model"

The problem that mbutcher and Degats are talking about is that apparently some people are connecting with VOB mods and causing bad collisions, as if their collision box has been changed and the 'mysterious' part is they are not getting an OOS kick in this case.

It's not something that I can fix without being able to reproduce it. I've checked the code and if the code is working then the guest gets an OOS kick if any point or triangle of the physics mesh is different. Of course this is tested and known to be the case.

The easiest way around the OOS check but still use a VOB mod is as you say, to use a VOB mod that leaves the physics LOD unchanged. In that case the car's physics is not changed in any way and this should not be a problem online. I can't imagine anyone going to great lengths to somehow modify the exe to return correct OOS checks for modified physics boxes, as that would really be very difficult (I don't how they would even start with that) and pointless when there is a simple and safe alternative.

But just saying "more often than not, it turns out that the player involved has a VOB mod on the car they're driving" when there is a bad collision doesn't bring me any closer to the solution. I guess we need an example of a MOD that can bypass the OOS check, otherwise I am being asked to solve a problem that I cannot see, understand or reproduce.